Automount(1M) is used to facilitate the sharing of files and data among different systems. Although this can be accomplished using static mounts with NFS (Network File System), automount provides a better solution.
This article describes a method to share systems among users without requiring that a system "belong" to a specific user. In addition, some potential problems are discussed and suggested workarounds are provided.
It is assumed that the reader is a system or network administrator and is familiar with automount, NFS, and NIS (Network Information Services, previously known as YP or Yellow Pages). Readers not familiar with automount should refer to the article titled "Automount: An Introduction" in the November/December 1994 (Volume 5, Number 6) issue of Pipeline, or to one of the resources listed in the "References" section at the end of this article.
Assumptions
The example in this article makes the following assumptions:
This article assumes that the environment is one of a university or research lab where the NIS and NFS servers are in a restricted area, and the SGI systems are in an area open to all. It is important in configurations such as this that users have access to their home directory and files regardless of the system they login to.
Organizing the User Community
The system administrator has the task of determining how to divide the users among the three NFS servers. There are many ways of doing this. One way is to split the user community into groups. For a university, it may be appropriate to assign one or more classes to each of the NFS servers. For a research facility or other organization, it might make sense to divide them by project or department.
There are advantages to dividing the user community into groups. The utilities and files that each group needs to access may be different, and it may be easier to provide a custom environment and backup scheme for an identifiable group of users.
As the size of the user population grows, the system administrator has to deal with increased disk space requirements. Depending on the desired filesystem layout, the system administrator may choose to make /usr/people a separate filesystem and to increase its size using logical volumes, or to make each class or project a separate filesystem under /usr/people.
Care should be taken when determining directory names. User home directories with long names can be both awkward for users and can create problems with backups. There are utilities such as bru(1) that have a 127 character filename restriction.
It is the responsibility of the system administrator to determine the optimum solution for their site. Regardless of the organization of the user accounts, configuring the servers and clients is largely the same.
Using an Indirect Map
This example uses a type of indirect map called a "home" map. An indirect map was chosen as it minimizes the number of mounts that take place on a system. When a directory or filesystem in an indirect map is accessed via automount, only that filesystem is mounted. This feature helps to reduce the possibility of a large number of mounts taking place in a short period of time (often called a "mount storm").
An indirect map provides an additional benefit of allowing all user home directories to be mounted under a centrally located point in the client filesystem.
Configuring the NIS Master
This example assumes that there are six computer classes, and two classes are assigned to each of the three NFS servers. In addition, this example assumes that each class is a separate filesystem mounted under /usr/people.
All user directories are mounted under the directory /home on their respective systems. Be sure to remember that since the NFS servers will be exporting /usr/people to all the systems using an indirect map, the NFS-mounted home directories of each user will be in the form /home/usr/people/<class-name>/<user-name>.
john::1001:1001:John A:/home/usr/people/class101/john:/bin/csh mary::1002:1001:Mary Z:/home/usr/people/class101/mary:/bin/csh joe::1003:1002:Joe B:/home/usr/people/class102/joe:/bin/csh jane::1004:1002:Jane F:/home/usr/people/class102/jane:/bin/csh mark::1011:1014:Mark E:/home/usr/people/class324/mark:/bin/csh kate::1012:1014:Kate G:/home/usr/people/class324/kate:/bin/csh rick::1013:1015:Rick L:/home/usr/people/class325/rick:/bin/csh amy::1014:1015:Amy I:/home/usr/people/class325/amy:/bin/csh kim::1021:1023:Kim Y:/home/usr/people/class503/kim:/bin/csh dan::1022:1023:Dan M:/home/usr/people/class503/dan:/bin/csh sue::1023:1024:Sue R:/home/usr/people/class504/sue:/bin/csh bob::1024:1024:Bob P:/home/usr/people/class504/bob:/bin/csh
To add group IDs for each of these classes, edit the file /etc/group and add the following lines at the end of the file:
class101::1001 class102::1002 class324::1014 class325::1015 class503::1023 class504::1024There are many different ways of choosing and assigning a default password. One way is to change the password of one person in each class to a predetermined string (e.g., the name of the class or project). Then, using a system editor such as vi, copy and insert that encrypted password for each user in that class.
# /etc/auto.master for the NIS master chac # /home auto.home -nosuid,nodev,intr
# /etc/auto.home for the NIS master chac # using NFS servers corona, # tecate and bohemia class101 corona:/usr/people/class101 class102 corona:/usr/people/class102 class324 tecate:/usr/people/class324 class325 tecate:/usr/people/class325 class503 bohemia:/usr/people/class503 class504 bohemia:/usr/people/class504
# sample local.make.script that is sinclude'd # by make.script # # auto.indirect indirect automount YP map. # auto.direct direct automount YP map. # auto.master main auto.master automount map # auto.home homedir map for automounter HOME=auto.home localall: all $(HOME) auto.master auto.master: auto.master.time $(HOME): home.time auto.master.time: $(DIR)/auto.master -@if [ -f $(DIR)/auto.master ]; then \ sed -e '/^#/d' $(DIR)/auto.master | \ $(MAKEDBM) - $(YPDBDIR)/auto.master; \ touch auto.master.time; \ echo "Updated auto.master"; \ if [ ! $(NOPUSH) ]; then \ $(YPPUSH) auto.master; \ echo "pushed auto.master"; \ else \ : ; \ fi \ else \ echo\ "couldn't find $(DIR)/auto.master";\ fi home.time: $(DIR)/$(HOME) -@if [ -f $(DIR)/$(HOME) ]; then \ sed -e '/^#/d' $(DIR)/$(HOME) | \ $(MAKEDBM) - $(YPDBDIR)/$(HOME); \ touch home.time; \ echo "Updated $(HOME)"; \ if [ ! $(NOPUSH) ]; then \ $(YPPUSH) $(HOME); \ echo "pushed $(HOME)"; \ else \ : ; \ fi \ else \ echo "couldn't find $(DIR)/$(HOME)";\ fi
# /var/yp/ypmakeThe system should display something similar to the following. Note that both the password, auto.home and auto.master NIS databases have been created and pushed to all clients.
> updated passwd (17:55:55 11/11/94) Finding NIS servers: chac chac has been called. Status received from ypxfr on chac: Transfer not done: master's version isn't newer. Finding NIS servers: chac chac has been called. Status received from ypxfr on chac: Transfer not done: master's version isn't newer. < pushed passwd (17:55:56 11/11/94) > updated netid (17:55:58 11/11/94) Finding NIS servers: chac chac has been called. Status received from ypxfr on chac: Transfer not done: master's version isn't newer. < pushed netid (17:55:59 11/11/94) Updated auto.home Finding NIS servers: chac chac has been called. Status received from ypxfr on chac: Transfer not done: master's version isn't newer. pushed auto.home Updated auto.master Finding NIS servers: chac chac has been called. Status received from ypxfr on chac: Transfer not done: master's version isn't newer. pushed auto.master
Configuring the NFS Servers
corona: /usr/people/class101/john /usr/people/class101/mary /usr/people/class102/joe /usr/people/class102/jane tecate: /usr/people/class324/mark /usr/people/class324/kate /usr/people/class325/rick /usr/people/class325/amy bohemia: /usr/people/class503/kim /usr/people/class503/dan /usr/people/class504/sue /usr/people/class504/bob
corona: # foreach i (~john ~mary ~joe ~jane ) ? cp /etc/stdcshrc $i/.cshrc ? cp /etc/stdlogin $i/.login ? end tecate: # foreach i (~mark ~kate ~rick ~amy ) ? cp /etc/stdcshrc $i/.cshrc ? cp /etc/stdlogin $i/.login ? end bohemia: # foreach i (~kim ~dan ~sue ~bob ) ? cp /etc/stdcshrc $i/.cshrc ? cp /etc/stdlogin $i/.login ? endNow change the owner and group on each file, including the user's home directory.
corona:
# foreach i (~john ~mary ~joe ~jane )
? set name = "`basename $i`"
? set gid = \
"`ypmatch ${name} passwd | cut -d: -f4,4`"
? find $i -print | xargs chown "$name.$gid"
? end
tecate:
# foreach i (~mark ~kate ~rick ~amy )
? set name = "`basename $i`"
? set gid = \
"`ypmatch ${name} passwd | cut -d: -f4,4`"
? find $i -print | xargs chown "$name.$gid"
? end
bohemia:
# foreach i (~kim ~dan ~sue ~bob )
? set name = "`basename $i`"
? set gid = \
"`ypmatch ${name} passwd | cut -d: -f4,4`"
? find $i -print | xargs chown "$name.$gid"
? end
# exports file for NFS server corona /usr/people /usr/people/class101 -nohide /usr/people/class102 -nohide # exports file for NFS server tecate /usr/people /usr/people/class324 -nohide /usr/people/class325 -nohide # exports file for NFS server bohemia /usr/people /usr/people/class503 -nohide /usr/people/class504 -nohideUse of the -nohide option allows the SGI clients to execute one mount of /usr/people and have transparent access to all filesystems below that mount point that are exported -nohide. As the number of filesystems mounted under /usr/people increases, the usefulness of this option increases dramatically. For more information on the -nohide option, refer to the manual page for automount(1M).
Configuring the Clients
+:This line requests that the NIS database be consulted for all additional password information.
# chkconfig nfs on # chkconfig automount on # rebootIf the NFS software is not loaded on the system, it must be loaded using inst(1M). If the system administrator is not familiar with this procedure, please refer to chapters 3, "Starting an Installation", and chapters 4 and 5, "Using the [Inst] Main Menu" and "Using [Inst] Supplementary Menus" IRIX Admin: Software Installation and Licensing Manual (available on-line with InSight).
Security, NIS and Shadow Passwords
System security should be a major concern for those system administrators who are providing remote home directory access using NFS or automount. Even in an environment where these systems are isolated from the outside world, the information on them can still be compromised by naive or malicious users.
All reasonable care should be given to protecting system software as well as individual user data from compromise by other system users.
A detailed discussion of system security is outside the scope of this article. However, system administrators should be aware of one aspect of using NIS with shadow passwords. At this time, SGI does not provide support for the use of NIS and shadow passwords. This means that system administrators have to choose between the additional security provided with shadow passwords, or the convenience of maintaining user password and account information with NIS.
For more information on NIS and shadow passwords, interested readers should refer to the manual pages for shadow(4) and pwconv(1M) as well as the resources listed in the "References" section at the end of this article.
Potential Problems and Workarounds
Duplicate Accounts
There are a number of user accounts that exist on all SGI systems in /usr/people. These accounts include OutOfBox, guest, and 4Dgifts. It can become very confusing when these accounts are on the NFS servers and the automount clients. For example, if the user mary is logged onto a client, she could type cd ../../guest. This would change directories to the NFS server corona's guest account. Or, she could type cd ~guest and this would put her in the guest account on the system she is currently working on.
One solution to this problem is to remove the home directories of OutofBox and 4Dgifts from the NFS server (and the corresponding entries in /etc/passwd), and to move the home directory of guest to some (non-exported) location. Because the guest login is used by many different utilities on SGI systems, including inst(1M), the lp spooling system, and the Indigo Magic environment, it is strongly recommended that the system administrator not remove the guest account from either the NFS server or from the clients.
Account Icons on NFS Servers
If the NFS servers use the graphical login tool clogin(1), the system administrator probably does not want all of the potentially hundreds of user icons to be displayed on the graphics console. There are two ways to remedy this situation.
The chkconfig(1M) flag noiconlogin can be turned on to prevent the display of user icons on the console. Note that the system must be rebooted for this change to take effect.
# chkconfig noiconlogin on # rebootFor those situations where the system administrator prefers to retain some of the administrative and local icons, login as root, and use a system editor such as vi to edit the file /var/Cadmin/clogin.conf. At the end of this file, add a line for each user that says <user-name>:noshow. For example, to hide the account icon for mary on the system corona, add the following:
mary:noshow
Account Icons on NFS Clients
Although it might be convenient to present all of the user login icons on all of the client systems, this should be discouraged for several reasons.
In order to display the icons, each home directory has to be automounted. If there are any networking problems with any of the NFS servers, or if one of them is down for some reason, all of the systems hang until the problem is resolved. Even if all NFS servers are up and running and there are no network problems, there is a very substantial load on each system and on each NFS server while these mounts take place. Depending on the number of users, the system may be so busy that it may appear to be hung. It is strongly recommended that system administrators turn this feature off.
There are two ways to disable user login icons. If the chkconfig flag windowsystem is on and the flag visuallogin(4) is off, the standard xdm(1) login program runs instead of clogin. If both the windowsystem and visuallogin flags are off, then the standard Unix login(1) program is used. Remember that changes made to chkconfig flags do not take effect until the next system reboot.
Receiving and Sending Mail
Configuring mail so that users can access mail from any system is outside the scope of this article. Please refer to the article titled "NFS Mounting Mail With IRIX 5.3 and IRIX 6.0.1" on page 24 of this issue of Pipeline.
Conclusion
This article presented an example of how to use automount and indirect maps. This example illustrates how to share systems among users without requiring that a user be assigned to a particular system. System administrators considering a similar configuration are encouraged to refer to one of the references listed below for more information.
References
NIS Administration Guide, available on-line with InSight.
NFS Administration Guide, available on-line with InSight.
6.2 IRIX Admin Manual Set, available on-line with Insight.
"C2 Security under IRIX 5.1", November/December 1993 Pipeline, Vol. 4, No. 6, available on-line with InSight (if Support Advantage has been loaded).
"Automount: An Introduction", November/December 1994 Pipeline, Vol. 4, No. 6, available on-line with InSight (if Support Advantage has been loaded).
In addition, the following published books may be of assistance. The presence or absence of any particular reference should not be construed as a comment on its usefulness.
Managing NFS and NIS by Hal Stern, published by O'Reilly & Associates, Inc., ISBN 0-937175-75-7.
Practical UNIX Security by Garfinkel and Spafford, published by O'Reilly & Associates, Inc., ISBN 0-937175-72-2.
UNIX System Security by Patrick H. Wood & Stephen G., published by Kochan Hayden Books, ISBN 0-8104-6267-2.